Fix the following code review findings on aictrl-dev/cli PR #81 (head branch).
Run the relevant tests/linters after each change.

1. packages/cli/src/cli/cmd/run.ts:575-579 — session_error wiring lacks a behavioral test
   Detail: The new `emit("session_error", …)` emission on the primary `session.error` path is verified only by `run-schema-v1.test.ts`, which asserts that the *source text* of run.ts contains certain substrings (`classifySessionError(props.error)`, `emit("session_error"`, `emit("error"`). That grep-style assertion passes even if `classifySessionError` is not imported, if the emit key is mistyped, or if the surrounding control flow is broken — it never drives a real `session.error` and observes the emitted payload. Consider a behavioral test (stub/observe `emit` and assert the actual `session_error` event is produced with the right reason/code/message) so this wiring can't silently regress.
2. packages/cli/src/cli/cmd/run.ts:575-581 — session_error + error both emitted; confirm no double-count
   Detail: For primary `session.error`s, both the new structured `session_error` event and the existing generic `error` event are now emitted (and `UI.error` may still print afterward). If any consumer/observer subscribes to both channels, the same failure can be counted or reported twice. If dual emission is intentional (structured channel vs. legacy channel), a short comment noting that would help future readers; otherwise consider gating the legacy `error`/`UI.error` path when `session_error` is handled.
3. packages/cli/test/cli/run-schema-v1.test.ts:49 — Brittle hardcoded 1400-char window in structural test
   Detail: `source.slice(idx, idx + 1400)` anchors the assertion window to a magic number. If the `session.error` block grows past 1400 chars (more conditions, longer payloads), a target string can slide outside the window and the `toContain` checks either miss the intended region or force the magic number to be bumped on every change. Prefer anchoring the window to a stable boundary (e.g. slice to the matching closing brace / next event handler) or assert against the full source so the test degrades predictably.

Fix the following code review findings on aictrl-dev/cli PR #81 (head branch).
Run the relevant tests/linters after each change.

1. packages/cli/src/cli/cmd/run.ts:580 — session_error can be emitted more than once for one failure
   Detail: This PR adds a third `session_error` emitter — the in-loop `session.error` handler for the primary session — alongside two pre-existing ones: `loopDone.catch(...)` and the `promptResult` rejection handler (both already call classifySessionError + emit("session_error")). In a mid-run failure it is plausible that a `session.error` event is observed (firing this new emit) AND `promptResult`/`loop()` later rejects (firing an existing emit), producing two `session_error` JSON lines for a single logical failure. Telemetry/CI consumers that count or branch on `session_error` could double-count or act twice.

Consider guarding all three sites with a shared `let sessionErrorEmitted = false` (emit + set on first occurrence), or document the expected at-most-N semantics for consumers.
   Suggested fix: Introduce a single `let sessionErrorEmitted = false` flag in the run scope and short-circuit all three `session_error` emit sites behind it, so at most one `session_error` is emitted per run regardless of which failure paths fire.
2. packages/cli/test/cli/run-session-error-emit.test.ts:24 — Unexplained --conditions=browser on a CLI subprocess
   Detail: The spawned CLI is run under `bun run --conditions=browser`. For a CLI that depends on Node/Bun runtime APIs (process, fs, child_process, real network calls), forcing the `browser` export condition risks resolving browser-shimmed module exports — potentially a mocked/no-op SDK client that does not exercise the real session.error path the test intends to cover, letting the assertion pass for the wrong reason. If the flag is intentional (to pin a specific module resolution), a one-line comment explaining why would help reviewers; if not, drop it so the subprocess runs under default (node) conditions.
   Suggested fix: Drop `--conditions=browser` unless it is intentionally required; if required, add a comment explaining why the browser condition is needed for this CLI subprocess.
3. packages/cli/test/cli/run-session-error-emit.test.ts:31 — Behavioral test doesn't cover the new code path
   Detail: The test is described as a behavioral regression test for #81, but its failure trigger (`--model nonexistent-provider/nonexistent-model`) almost certainly exercises a PRE-EXISTING emitter rather than the new code this PR adds.

The new code (run.ts, in the `session.error` event handler) emits `session_error` when a `session.error` EVENT is observed during the loop — i.e. a session that started successfully and failed mid-execution. A nonexistent model fails earlier: per the base code's own comment in run.ts's `promptResult` rejection handler, "If SessionPrompt.prompt() rejects BEFORE it enters its internal loop() (e.g., Session.get() fails, model not found)" — i.e. it rejects `promptResult`, and that rejection handler ALREADY emits `session_error` (classifySessionError + emit), predating this PR.

Consequence: this test passes on the base branch unchanged; removing or breaking the new run.ts `emit("session_error", …)` would leave it green. It does not actually guard the #81 behavior and gives false confidence.

Fix: trigger an in-execution session.error event (a session that starts then fails mid-run, e.g. a valid provider + revoked/empty key → auth failure during the run) rather than a pre-prompt model-resolution failure, and assert the event originates from the in-loop path. A focused unit test that feeds a `session.error` event into the loop would also cover it deterministically.
   Suggested fix: Drive a real in-execution failure (valid provider + empty/revoked key so the session starts and fails mid-run with a 401/ProviderAuthError), or add a unit test that injects a `session.error` event into the loop and asserts `session_error` is emitted — so the assertion fails if the new in-loop emit is removed.